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(57) An electronic ticket includes user information, 
ticket application information, and a ticket object further 
including a ticket data object. A modular electronic ticket 
includes an XLM document divided into several XML 
parts, the parts further including user information, and 



individual tickets, the individual tickets further including 
user information, and ticket application information in- 
cluding a part for a ticket object with a link specified by 
a keyword to a ticket data object, the ticket data object 
being presented by a device when the ticket is to be 
used. 
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Description 

Field of the invention 

[0001] The invention relates generally to electronic 
tickets or documents, and, more specifically, to gener- 
ating, transferring, and presenting such tickets or docu- 
ments. 

Background of the invention 

[0002] Digital or electronic tickets have been under a 
growing interest among the general public. Therefore, 
various players in the industry have designed different 
approaches which are to enable a flexible and fast us- 
age of tickets without any compromising of the security. 
[0003] Because of the obvious advantages obtained 
by using a standardised methodology, the development 
work has lead to the establishment of several standard- 
isation bodies. An example of such a standardisation 
body is the Mobile electronic Transactions MeT. The 
MeT concentrates on various aspects relating to elec- 
tronic transactions and currently (August 14, 2002) has 
a website www.mobiletransaction.org. 
[0004] The technology used for the administration 
and usage of tickets needs to be defined in order for 
electronic tickets to reach a commercial success. The 
MeT has so far published a Discussion Document MeT 
Ticketing Framework, Version 1.0 (21 February 2001) 
which at the moment may (August 14, 2002) be down- 
loaded from http ://www. mobiletransaction.org/pdf/ 
R 1 1 /M eT-Ti cket i n g - F ram ewo rk-R11.pdf, which is here- 
by incorporated as reference. 

[0005] Figure 1 illustrates a system in which electronic 
tickets may be used. A ticket is issued by a ticket issuing 
system 101 which is connected to a communications 
network, such as the Internet 1 00B usually via its front 
end 1011. Most ticket issuing systems 101 include a 
back end 1012 which performs the ticketing and stores 
a copy of issued tickets to a data storage 1013. When 
a ticket has been generated in the ticket issuing system 
101 , it is usually sent to a personal computer 1 04 via the 
Internet 100B, or to some mobile device 102 or 103, 
which may be connected to the Internet 1 00B either di- 
rectly or via a mobile network 100A. 
[0006] Tickets may be ordered directly from the per- 
sonal computer 104. or from the mobile devices 102, 
103. Some ticket models are push-type, wherein the 
ticket issuing system pushes the ticket to the device of 
the end-user, whereas some ticket models are pull-type 
which involve a request from the end-user device before 
the ticket is generated. Further, a ticket may be ordered 
by a first mobile device 102 and used by the user of a 
second mobile device 103. 

[0007] Further, usually the system contains an in- 
spection system 1 06 which is intented to checkthe tick- 
ets. After checking the tickets a person presenting the 
ticket is allowed the service, such as entering an air- 



plane or through a gate. Because electronic tickets may 
be used within a communications network, such as the 
Internet 100B, for paying also services available in the 
network, the nature of the inspection system is not lim- 

5 ited to these but may involve also other tasks. 

[0008] In some cases the system also includes a tick- 
et printer 1 05. This kind of approach has proved partic- 
ularly valuable when the service provider in question is 
willing to enable the use of traditional tickets as well. 

10 The conventional paper-form tickets are fast to check 
by a human inspector. Thus it may be beneficiary to print 
a paper ticket of an electronic ticket with which the user 
is then allowed the service. Therefore the ticket printer 
1 05, which may also be connected to the Internet 1 00B, 

15 for example, may obtain instructions from the ticket is- 
suing system 1 01 relating to what kinds of tickets to ac- 
cept, and so forth. Ticket printer 1 05 may include similar 
functionalities to the inspection system 106. 
[0009] Evidently, there is not yet any agreement about 

20 the future format of an electronic ticket. Some solutions 
used by current vendors and already being available in 
the market seem not to be satisfactory in all aspects. 
Thus there still exists a need for a flexible and general 
ticket concept which provides the ticket issuers and us- 

25 ers of the tickets with a high enough security level, and 
which is technically efficient to use whatever the final 
form of the electronic appearance of the electronic ticket 
will be. 

[0010] Especially the inspectioning of the electronic 
30 ticket has preferably to be fast, reliable and it should not 
consume too much air interface nor introduce too much 
disturbances into the air interface. 
[0011] Firstly, the handling of modular tickets or ticket 
booklets in the user terminal has not been described yet 
35 in the state of the art literature. Especially tricky it is. if 
the handling is to be performed by one application which 
is a single logical entity. Secondly, the handling of doc- 
uments, such as tickets, receipts, medical records, med- 
ical prescriptions, or hotel vouchers, all containing some 
40 user information content, is extremely difficult by using 
prior art solutions. Thirdly, the existing systems are 
hardly customisable thus providing the ticket vendors 
only a few degrees of freedom. 

[001 2] It is an object of the invention to bring about a 
45 solution by means of which it is possible to obtain a re- 
liable, efficient and flexible ticketing platform. Another 
object is to provide a solution by means of which it is 
possible to use electronic tickets in a convenient way. 
Still another object of the invention is to bring about a 
50 novel electronic ticket model. 

Summary of the invention 

[0013] This and other objectives of the invention are 
55 accomplished in accordance with the principles of the 
present invention as described in the patent claims. 
[001 4] A device for presenting an electronic ticket in- 
cludes i) receiving means for receiving an electronic 
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ticket from a ticket issuing system, the electronic ticket 
including user information, ticket application informa- 
tion, and ticket object, ii) a ticket storage for storing the 
ticket, iii) parsing means for detecting a predefined key- 
word in the ticket object thus generating a parsing result, 
and iv) generation means responsive to the parsing 
means for generating a presentation command for pre- 
senting means adapted to present a ticket data object 
defined by a link including the keyword, if the parsing 
result is that the predefined keyword is detected. With 
such a device the electronic tickets may be used in an 
easy manner, and the presenting of an electric ticket 
saves resources because only the ticket data object is 
presented. 

[0015] A system for issuing electronic tickets includes 

i) generating means for generating an electronic ticket 
including user information, ticket application informa- 
tion, and ticket object, wherein the generating means 
generate a link indluding a predefined keyword into the 
ticket object, the link defining a ticket data object, and 

ii) sending means adapted to send the electronic ticket 
and the ticket data object to a device. With such a sys- 
tem automated generation and transferring of electronic 
tickets is achieved. 

[0016] A system for using electronic tickets includes 
i) a system for issuing electronic tickets adapted to send 
electronic tickets to a device, an electronic ticket includ- 
ing user information, ticket application information, and 
ticket object, ii) a device for presenting an electronic tick- 
et comprising 1 ) a ticket storage for storing at least one 
electronic ticket, 2) parsing means for detecting a pre- 
defined keyword in the ticket object, and 3) generation 
means responsive to the parsing means for generating 
a presentation command for presenting means if the 
parsing result is that the predefined keyword is detected, 
and iii) a device for inspecting tickets, the device having 
a predefined address and including 1) receiving means 
for receiving a ticket data object from a device, the ticket 
data object being defined in the device by a link including 
a keyword, 2) checking means for checking the contents 
of the object received, the means producing a checking 
result, and 3) entry means responsive to the checking 
means, adapted to allow entry, if the checking result 
shows that the ticket data object corresponds to a valid 
ticket, and/orforbid entry in the opposite case. With such 
a system for using electronic tickets, the benefits of elec- 
tronic tickets can be utilised in an effective manner. 
[0017] An electronic ticket includes i) user informa- 
tion, ii) ticket application information, and iii) ticket object 
further including a ticket data object. An electronic ticket 
having such a structure enables the efficient presenta- 
tion of the ticket data object. 

[0018] A modular electronic ticket includes an XLM 
document divided into several XML parts, the parts fur- 
ther including i) user information, and ii) individual tick- 
ets, the individual tickets further including 1) user infor- 
mation, and 2) ticket application information including a 
part for a ticket object with a link specified by a keyword 



to a ticket data object, the ticket data object being pre- 
sented by a device when the ticket is to be used. With 
such a device the electronic tickets may be used in an 
easy manner, and the presenting of an electric ticket 
5 saves resources because only the ticket data object is 
presented. 

[0019] Means for performing an operation on a ticket 
including at least one XML based document whose 
model derives through XLM schemas of basic user in- 
fo formation type by extending it, several of these tickets 
being delivered together using the stucture provided by 
the modular ticket. With such means, automated oper- 
ations of electronic tickets are achieved. 

15 Brief description of the drawings 

[0020] In the following, the invention and its preferred 
embodiments are described more closely referring to 
the examples shown in Figures 2 to 1 1 in the appended 
20 drawings, wherein 

Figure 1 illustrates a system for providing and using 
electronic tickets, 



25 Figure 2 is a block diagram of a mobile device 1 02 
adapted to carry out the present invention , 

Figure 3 illustrates a possible format for the ticket 
300, 

30 

Figure 4 illustrates the relation between a keyword 
402 and the ticket data object 403, the key- 
word 402 being included in the ticket 300, 

35 Figure 5 is a block diagram of the ticket issuing sys- 
tem 103, 

Figure 6 is a block diagram of the inspection sys- 
tem 1 05 and ticket printer 1 06, 

40 

Figure 7 illustrates more closely the contents of the 
ticket 300, 

Figure 8 illustrates the structure of a modular ticket 
45 350 and tickets 350' and 350", 

Figure 9A shows a first possibility how the ticket 
300A is presented to the ticket inpection 
system 106, 

50 

Figure 9B shows a second possibility of presenting 
the ticket 300A to the ticket inspection sys- 
tem 106, 

55 Figure 10 shows how a modular ticket 350 and a pre- 
scription 300'" may be ordered from re- 
spective ticket issuing systems 101 A, 
101 B, and 
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Figure 1 1 illustrates the summary of the ticket con- 
cept. 

[0021] Like preference signs refer to corresponding 
parts and elements throughout the Figures 1 -10. 

Detailed description of the invention 

[0022] Figure 2 is a block diagram of the mobile de- 
vice 1 02. In principle, the mobile device 1 02 can be any 
portable device, such as a Personal Digital Assistant 
PDA, a laptop computer, a Portable Digital Wallet, a Per- 
sonal Trusted Device PTD, but in the following it is for 
simplicity assumed that the mobile device is a mobile 
phone having capabilities to be in connection via the mo- 
bile network 1 00A and the Internet 1 00B with the ticket 
issuing system 101 . 

[0023] The mobile device 1 02 includes input/output I/ 
O means 260, which include receiving means 263, 
sending means 262 and a display 261 . Further, the mo- 
bile device 1 02 may also include a loudspeaker264 and 
a Radio Frequency RF tag 265. The RF tag is usually a 
contactless smartcard. On the market there are also 
some models known as hybrid smart cards containing 
both an electrical interface, preferably to the SIM card, 
and an RF interface. 

[0024] The mobile device 102 includes also security 
means 250. If the mobile device 1 02 is a mobile phone, 
the security means 250 then further comprise a Secure 
Element SE 252, such as a Subscriber Identity Module 
SIM similar to the SIM card used in the Global System 
for Mobile communications GSM , or User Identity Mod- 
ule UIM such as designed forthe coming Universal Mo- 
bile Telecommunication System UMTS. Other well- 
known secure elements include Wireless Identity Mod- 
ule WIM such as that used in the Wireless Application 
Protocol WAP standard. The WIM provides crypto- 
graphic services, such as encryption, utilising Public 
Key Infrastructure certificates, and handling and gener- 
ation of digital signatures for different mobile based ap- 
plications. Some devices such as the PTD include a 
cryptographic library as well. 

[0025] The secure element 252 may further include a 
trusted agent 254 whose purpose is to interact with the 
ticket issuing system 101 . Another purpose of the se- 
cure element 252 is to interact with the inspector 106 
and the ticket printer 1 05 using the ticket application 200 
in the mobile device 1 02. Even though the ticket issuing 
system 101 , ticket printer 105 and the ticket inspecting 
system 106 are presented as separate entities, they 
may well be run by one party, and all be incorporated in 
one device. 

[0026] In the following it is assumed that the SE is a 
smart card which offers among others, PKI services to 
the ticket application. Obviously it can also be some 
hardware element or even a software element. 
[0027] A ticket that is received from the ticket issuing 
system 101 is stored into ticket storage 230 such as a 



database or memory including a register. The ticket stor- 
age 230 includes electronic tickets and serves them to 
the ticket application 200. 

[0028] The User Interface U/l part 201 of the ticket ap- 
5 plication 200 performs various functions. Firstly, with the 

help of the U/l part 201 the user may subscribe tickets 

from the ticket issuing system 101. Secondly, the U/l 

part 201 notifies the user whenever a ticket is received. 

The user may then have an opportunity to confirm the 
10 ticket. Thirdly, when the user is willing to use the ticket, 

he/she may select the ticket to be presented from a 

menu in the U/l part 201 . 

[0029] The ticket application 200 in the mobile device 
1 02 further comprises parsing means 202, comparison 

15 means 204, and generation means 206. 

[0030] When a ticket is to be used, the parsing means 
202 read the contents of the ticket. Because the ticket 
may contain an extensible Markup Language XML 
frame, the parsing means 202 are adapted to detect a 

20 predefined keyword. The point of the keyword defines 
a link to a ticket data object. The parsing means 202 go 
thus through the parseable part of the ticket and produce 
a parsing result. 

[0031] In the comparison means 204 the parsing re- 

25 suit is checked. If the parsing result indicates that the 
keyword was detected, i.e. that the position of the object 
oralinkto the object was found, in the generation means 
206 a presenting request is generated. In the opposite 
case no presenting request will be generated. The se- 

30 lection of the presenting means 260B may be con- 
strained or indicated explicitly by the issuer; then the 
presentating means 260B are specified within the ticket 
application information, PTD information, or presenta- 
tion information. 

35 [0032] The presenting request will be passed to the 
presenting means 260B possibly comprising of a plural- 
ity of presenting means 260B, such as display 261 , 
sending means 262, loudspeaker 264, and RFtag 265, 
depending on the ticket type. The presenting means 

40 260B present the ticket data object. According to the 
presenting means 260B, the presenting of the object 
may take place by displaying it on the display 261 , such 
as a barcode or an image, by playing it through a the 
loudspeaker264thus producing an aurally recognisable 

45 tone, by beaconing the object i.e. storing the object as 
a whole or only an ID refererringto the object into an RF 
tag 265, which then beacons the object when brough 
close enough to a checkpoint, or in some other suitable 
way. 

50 [0033] One possibility for presenting the ticket data 
object is to present it using the sending means 262. Pos- 
sibilities for the sending means 262 include normal mo- 
bile phone communication methods, i.e. sendingthe ob- 
ject via a mobile network communication channel, such 

55 as per short message SMS oramultimediaservice mes- 
sage MMS, or in a data packet. Also other possibilities 
exist, such as presenting the ticket data object by using 
a low-power RF chip such as the BLUETOOTH, or by 
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presenting it using infra-red such as IrDA means ; and 
so forth. If some of the mobile network communication 
channels or BLUETOOTH is to be used, the presenta- 
tion of the object is then preferably addressed to a pre- 
defined address in order for the recipient of the presen- 
tation, i.e. the inspection system 105 or the ticket printer 
105 or 1 06 receives the presentation. 
[0034] Figure 3 illustrates a possible structure of a 
ticket 300. The ticket includes user information 301 , tick- 
et application information 302, and ticket object 303. Us- 
er information 301 is information to the user on the serv- 
ices, terms, and conditions of the digital ticket. Ticket 
application information 302 is information necessary to 
the ticket application 200 to manipulate a ticket data ob- 
ject 403. namely the ticket object 303 comprises a link 
to the ticket data object 403. 

[0035] The extensible Markup Language XML has 
been proposed to be used for electronic tickets in "XML 
Ticket: Generalized Digital Ticket Definition Language" 
by Ko Fujimura, Yoshiaki Nakajima, and Jun Sekine and 
at the time of writing (August 1 4, 2002) available at http: 
//www. w3. org/Dsig/signed-XML99/pp/NTT_xml_ticket. 
html. 

[0036] The XML is intended to define individual ele- 
ments of the tickets (e.g. Ticketlssuer, TicketID, Ticket 
typelD) that are used by the mobile devoce ticket appli- 
cation and the merchant's system alike. Thus, in the pri- 
or art approaches the ticket object has actually been the 
full XML document. Consequently, the XML document 
will need to be uploaded as a whole to the merchant for 
processing and authentication in order to obtain the 
service for which the ticket has been issued. 
[0037] Possible XML elements and attributes to be 
used for electronic tickets are currently being defined. 
As already discussed, different services may require dif- 
ferent schemas, such as those of ARTS for receipts, and 
ASTM for medical records. These efforts do not allow 
embedding variable content proprietary to a given issu- 
er, because no ticket data object is involved. 
[0038] Figure 4 presents the present invention more 
closely. The ticket object 303 contains a frame 401 
which is a part of the ticket 300 including ticket applica- 
tion information 302, and ticket data object 403. The 
frame 401 includes a keyword 402 that indicates the link 
404 pointing to the ticket data object 403. In other words, 
theticket object 303 contains a Iink404to the ticket data 
object 403 which is an external entity. The ticket data 
object 403 grants upon presentation access to the prom- 
ised service. 

[0039] In accordance with the present invention, the 
service is not to be provided upon the presentation of 
the ticket 300, i.e. not presenting the XML document it- 
self, but upon presenting a ticket data object 403. The 
ticket data object 403 may be of arbitrary format and 
content. The ticket data object 403 will be embedded in 
the ticket 300 through the link 404 that appears in the 
ticket application information 302 in the ticket 300. In 
this respect, the ticket data object 403 has been 



wrapped into the ticket 300, but it does not need to be 
transported together with the ticket 300. The ticket 300 
is an XML document, and it has to be transported to the 
mobile device 102 in one go in order to enable a con- 

5 sistent storing into the ticket storage 230. If the ticket 
application 200 has no means to relate the ticket data 
object 403. the ticket data object 403 has also to be 
transported at the same time. In Figure 3 terms, thetick- 
et object 303 includes the keyword 402 that indicates 

10 the presence of a ticket data object 403. The ticket data 
object 403, may be in an arbitrary format, even an XML 
document. 

[0040] Figure 5 is a simplified block diagram of aticket 
issuing system 1 01 . The ticket issuing system includes 
15 a front end 1011, a back end 1012, security means 503, 
generating means 501 , sending means 502, and aticket 
storage 1013. 

[0041] The front end 1 01 1 takes care of user interfac- 
es and interfaces to and from the network, such as the 
20 Internet 100B. The front end 1011 performs various 
tasks, such as autorisation and authentication. 
[0042] The back end 1012 is the ticketing platform it- 
self. It runs a ticket storage 1013, whereto tickets gen- 
erated by the generating means 501 are stored. Further. 
25 the generated tickets may be signed in the security 
means 503 prior to sending the tickets to the user. The 
sending is done by the sending means 502. Similarly, 
copies of the tickets may be sent to the ticket printer 1 05 
and to the inspection system 1 06. 
30 [0043] According to one aspect of the present inven- 
tion, the ticket 300 or modular ticket 350 delivered may 
include a promotional object with an external reference. 
Such a promotional object may be a ringing tone or an 
icon or a screen saver. The promotional object may be 
35 retrievable by the user or it may be embedded into the 
ticket 300. This kind of approach is useful when offering 
the tickets for some customer segments, i.e. by pur- 
chasing a specific ticket one can obtain an extra logo, 
ringing tone, or a screen saver for free or for a reduced 
40 price. 

[0044] A goal is that the modular ticket behaves as a 
single logical entity even though might contain several 
individual tickets. In the other hand, the ticket applica- 
tion should be able to use the operations available to 
45 manipulate the user information of the tickets to handle 
XML-based documents of similar user experience. 
[0045] Figure 6 is a simplified block diagram of aticket 
printer 105 and an inspection system 106. The ticket 
printer 1 05 and inspection system 1 06 contain receiving 
50 means 601 , checking means 603, entry means 605, and 
aticket storage 607. 

[0046] Data relating to tickets generated in the ticket 
issuing system 101 is transferred to the ticket storage 
607. Such data may include serial numbers and a ge- 
55 neric format of an object 403G. 

[0047] The receiving means 601 receive a ticket data 
object 403 from a user willing to obtain a printed ticket 
or to use a service. The receiving means 601 may fur- 
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ther contain a sensor 601' as will be discussed below 
with reference to Figure 9B. The ticket data object 403 
received from the user is then compared to the generic 
ticket models stored in the ticket storage 607, the com- 
parison producing a comparison result. If the compari- 
son result shows that the ticket is valid, the entry means 
605 produce the service, allow the user to enter, print 
the ticket or so forth. 

[0048] The serial numbers forthe tickets may be com- 
bined with the generic format of the ticket data object 
403G. The ticket data object 403 presented by the user 
may be compared with all possible combinations of the 
ticket data object 403G filtered through the serial num- 
bers. 

[0049] In accordance with one aspect of the present 
invention, the content and form of the ticket data object 
403 is left totally proprietary to the merchant. The ticket 
data object 403 may correspond to plain text, e.g. to a 
proprietary alphanumeric code indicating a given ticket 
product. It may also be an optically or visually recognis- 
able pattern, such as a barcode, or a picture. Further, 
the ticket data object 403 may include proprietary en- 
coding e.g. in a picture in orderto increase security. The 
encoding used for the ticket data object 403 may be tick- 
et 300 based, i.e. the encoding in the ticket data object 
403 is unique for each user. In this case, the subscriber 
using the ticket may be identified. The ticket data object 
can also be a XML document itself, but including propi- 
etary syntax to the merchant, in order to represent ele- 
ments and information that are in accordance with the 
merchants (issuer/inspector) needs. The encoding can 
be made depending of user information or the ticket 
unique identifier. 

[0050] Nonetheless, the XML ticket-information ele- 
ments in the frame 401 will be used to provide a con- 
sistent experience to the user with regards to the type 
of ticket 300. Other usage experience issues may relate 
to the date of usage, and to other considerations that, 
on one hand, enable the ticket issuing system 101 ad- 
ministrators and the ticket printer 1 05 or inspection sys- 
tem 106 administrators high enough flexibility for per- 
sonalising their tickets according to their needs. On the 
other hand, they ensure that the user feels more com- 
fortable because the user interface remains constant 
even if the actual physical or electrical realisation of the 
ticket changes. Not only tickets, the user can operate 
medical records, prescriptions, coupons, receipts, and 
basically all electric documents in a consistent way thus 
reducing the threshold caused by the need to adapt new 
user interfaces and learn to use new services. 
[0051] Some of these Consistent User Experience 
CUE information elements, i.e. cue ticket-info elements 
are undercurrent specification in the MeT. 
[0052] In accordance with one aspect of the present 
invention, the contents of the frame 401, i.e. the ele- 
ments or format required by theticket inspector 1 05, 1 06 
processing systems are left to a high extent proprietary 
to the merchants and ticket issuing system 101 admin- 



istrators in orderto support backward compatibility, and 
especially, to suit particular business needs. 
[0053] The ticket 300 will have three interfaces: the 
first to the user throughout the user information 301 , 

5 then to the ticket application through the information in 
302-701 -703, 705,707, and the last one to the ticket is- 
suing system 1 01 or inspector 1 05, 1 06 throughout the 
ticket data object 403 which is an external ticket entity 
and contains the real ticket value. This ticket data object 

10 403 is used by the ticket inspector 1 05 or ticket printer 
1 06 to validate the ticket and judge about the granting 
of access to services. 

[0054] Figure 7 illustrates more closely the structure 
of a ticket 300. The ticket can be identified by the ticket 

15 issuing system 1 01 , ticket printer 1 05, or by the inspec- 
tion system 106 from the user information 301 part of 
theticket. For some applications, such as for airline tick- 
ets, it is necessary that the legitimate user can be iden- 
tified from this part, whereas for some other applications 

20 it is beneficiary to provide user anonymity, such as for 
coupons or vouchers e.g. for public transportation. 
Therefore the user information 301 may contain a clear- 
text identifier relating to the user, the user name encrypt- 
ed, or other identifier. 

25 [0055] The user information 301 appears in all ticket 
types, e.g. eventtickets, airline tickets, receipts, medical 
prescriptions, medical records, vouchers etc. It may in- 
clude information to the user on the services, and the 
terms and conditions of the digital ticket 300. The ele- 

30 ments and attributes of the user information are defined 
by means of different ticket data types in independent 
XML schemas. All the ticket data types defined in the 
new schemas derive from a basic ticket data type, in- 
cluding at least user information 301 . This permits the 

35 ticket application throughout the definition of modular 
ticket 350 to validate new ticket data types. 
[0056] The user name does not need to be encrypted. 
If the user wants to protect this information he or she 
can use the services of the ticket application 200 to ac- 

40 cess the ticket data storage 230 through a password or 
PIN code entry. The issuer might want though, to protect 
the ticket data object 403 through encryption. To identify 
the user, the ticket data objct 403 may carry the personal 
information of the user. 

45 [0057] Ticket application information 302 is optional 
in the basic ticketing schema. This part appears in those 
ticket types that require the use of a ticket data object 
and thus need to specify the presentation method and 
security. Ticket application information 302 includes Se- 

50 cure Element SE information 701 and PTD information 
703. Ticket application information 302 thus contains in- 
formation necessary to the ticket application 200 to ma- 
nipulate a ticket data object 403. 
[0058] SE information 701 and security information 

55 707 include information on the requirements for secure 
handling of the ticket data object 403 by the security 
means 250 present in the mobile device 1 02. The serv- 
ices provided by the security means 250, such as by the 
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SE 252, to the ticket application regarding to the han- 
dling of a given ticket data object 403 are initially related 
to copy protection mechanisms by means of Public Key 
Infrastructure PKI, tamper proof storage, PKI encryp- 
tion, and authentication by means of digital signature 
services. 

[0059] Presentation information 705 indicates the 
ticket application 200 the only feasible presenting 
means 260B for presenting the ticket data object 403 to 
the inspector 1 06 or to the ticket printer 1 05. This infor- 
mation may be used in the generation means 206 of the 
ticket application 200. 

[0060] Security information 707 indicates to the ticket 
application 200 located in the mobile device 1 02 the se- 
curity model that needs to be applied to the ticket data 
objects 403 at the ticket application 200 level. This se- 
cure handling initially includes two topics, namely i) ap- 
plication services access control, and ii) ticket data ob- 
ject 403 access control. 

[0061] The application services access control refers 
to the operations that are allowed to a given ticket data 
object 403. This security service is provided by the own 
implementation of the ticket application 200. The serv- 
ices of the ticket application 200 that are provided to the 
ticket data object 403 are in accordance with the decla- 
ration in this part of the ticket 300. For example, the ap- 
plication services access control may indicate that the 
ticket data object 403 must not be transferred or backed 
up. Since the ticket application may or may not use 
tamper proof mechanisms, such as code obfuscation, 
this level of security is only valid to prevent attacks by a 
general user or an occasional hacker. 
[0062] Therefore, ticket data access control refers to 
the access by the user to a given ticket data object 403. 
The later might be requested by the ticket issuing sys- 
tem 101 to be protected by a Personal Identification 
Number, or by encryption, e.g. symmetric encryption. 
These security services are provided by the local mobile 
device resources in contrast to the use of the SE. 
[0063] According to one aspect of the present inven- 
tion, the ticket data object 403 may also be included in 
the ticket application information part 302. The link 404 
including the keyword 402 and pointing to the ticket ob- 
ject preferably is located in the ticket object 303. 
[0064] Secure element information 701 indicates se- 
curity requirements to be supplied by the SE 252, or oth- 
er means included in the security means 250. Transport 
information 705 indicates the presentation method to be 
used for presenting the ticket 300. The identifiers 707 
relating to application level security indicate security re- 
quirements to be supplied by the application level. The 
requirements may relate to the geographical location 
where the ticket is to be used, such as for local traffic 
tickets, or the device identity or user identity, needed for 
obtaining a reliable but flexible copy protection mecha- 
nism. 

[0065] The ticket data object 403 may have encrypted 
proprietary format, or any otherformatas well. Its format 



is preferably defined by the ticket issuing system 101 , 
and, the ticket data object 403 may be traded by some 
given services. This object is a reference to by a link 404 
indicated by a keyword 402 in the ticket 300, preferably 
5 in the XML document part included in the ticket object 
303, or the PTD information 703. 
[0066] The ticket data object 403, as already dis- 
cussed, may include sound data, i.e. the ticket data ob- 
ject 403 is a sound file, video data (video file). Similarly, 
10 the ticket data object 403 may be an XML document 
having a proprietary syntax, or, it may be a two dimen- 
sional bar code or any other optically readable or rec- 
ognisable object. The presentation of the ticket data ob- 
ject 403 might be in a frequency detectable by human 
15 hearing, or in a range of high or low frequencies detect- 
able by a specific device. The sequence of aural infor- 
mation (pitch and timing) would represent the aural tick- 
et, much in the same way an arrangement of pixels will 
represent a pictorial ticket. 
20 [0067] Figure 8 shows one possible structure for a 
modularticket 350. The modularticket 350 contains us- 
er information 301, and then a bunch of tickets data 
300A, 300B and 300C. Further, there is a receipt 300D 
for the purchase of the modular ticket 350. The ticket 
25 350' includes user information 301' and ticket object 
303'. Theticket 350" includes user information 301 " and 
ticket object 303". The tickets 350' and 350" do not con- 
tain more than one ticket 300', 300". 
[0068] The ticket data objects 403A, 403B, 403C of 
30 the modular ticket 350 are also stored in the data stor- 
age 230 of the mobile device 1 02. However, if they cor- 
respond to like tickets, the ticket data objects 403A, 
403B, 403C do not then need to be stored in triplicate, 
but it suffices if one general model to be used as the 
35 ticket data object 403A, 403B, 403C is stored. Further 
the ticket data objects 403A, 403B, 403C do not need 
to be transported from the ticket issuing system 101 si- 
multaneously, or at the same time as the modularticket 
350 is received atthe mobileterminal 102, butthetrans- 
40 port may be delayed to a later moment of time, e.g. for 
security purposes, because apparently this kind of an 
approach may reduce the risk of the user tampering the 
ticket data object 403A, 403B, 403C. The later moment 
of time may be a moment closer the defined moment 
45 when some of the tickets 300A, 300B, 300C is going to 
be used, such as might be the case when the modular 
ticket 350 were a bunch of flight tickets. 
[0069] The tickets 300, 300' and 300" are stored into 
the ticket storage 230. Preferably, it is a database for 
50 tickets in the end user's mobile device. The ticket 300 
has similar structure in the database. The individual tick- 
ets have respective objects, 403, 403' and 403", where 
the object 403' relates to ticket 300' and the object 403" 
to ticket 300". Further, each modular ticket 350 for a 
55 bunch of tickets 300A, 300B and 300C may contain a 
receipt 300D of purchase. The receipt 303D may be 
stored or moved into a separate receipt database which 
again can be located in the mobile device or in a network 
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data repository. 

[0070] In other words, a modular ticket 350 includes 
user information 301 and several individual tickets 
300A, 300B, 300C. Each individual ticket 300A, 300B, 
300Cthen includes user information 301 A, 301 B, 301 C 
and ticket application information 302A, 302B, 302C, if 
the ticket issuer is willing to use any ticket data object 
403A, 403B. 403C. This means thatthe user information 
contained in the individual tickets 300A, 300B, 300C 
may be different to each other, and further that the user 
information 301 included in a modular ticket 350 maybe 
different from the user information 301 A, 301 B, 301 C in 
the individual tickets 300A : 300B, 300C contained in the 
modular ticket 350. 

[0071] In the prior art solutions there has not been any 
convenient possibility for delivering information on the 
general terms and conditions of usage of the ticket to 
the user. In accordance with the present invention, the 
modular ticket 350 includes a user information part 301 
on the general terms and conditions of the ticket. The 
service is confirmed by the digital signature in the ticket 
300. 

[0072] I n the previous solutions, the validity of the tick- 
et could only be determined by the ticket issuer, e.g. by 
verifying the signature, and not by the party offering the 
service package. According to the present invention , the 
modular ticket approach offers a non-repudiation serv- 
ice through the digital signature of the entity issuer of 
the modular ticket 350. 

[0073] Different tickets 300A, 300B, 300C, 300' and 
300" which require extremely similar operations to those 
done for the classical digital tickets, i.e. obtaining and 
browsing tickets, accessing services, transferring and 
backing up tickets, may be realised with a plurality of 
dedicated ticket applications 200. This approach is not 
optimal from the point of view of code reuse. Secondly, 
it wastes the capacity of the mobile device 1 02. In addi- 
tion, such an approach does not benefit from the oper- 
ational knowledge that a user might already have from 
the ticket application 200. He or she expects to be able 
to have a similar user interface for most uses of tickets, 
which can simply be provided, according to the present 
invention, by the same U/l part 201 for more ticket ap- 
plications 200, or by using the same ticket application 

200 for different kinds of electronic tickets. 

[0074] Figure 9A illustrates closer a first possibility for 
the presentation mechanism. The ticket 300A is pre- 
sented by the user of a mobile device 102 to a ticket 
inspector 106. 

[0075] The user selects with the help of the U/l part 

201 of the ticket application 200 a ticket 300A from a 
modular ticket 350 including the bunch of tickets 300A, 
300B, 300C. The ticket application 200 reads the ticket 
object 303A of the ticket 300A, detects from the XML 
frame in the ticket data a keyword 402 indicating a link 
404 pointing to the ticket data object 403 of the ticket 
300A. Then the ticket application 200 reads the ticket 
data object 403 which may be stored in the data storage 



230. The generation means 206 generate a presenting 
command for presenting means 260B, the presenting 
command being specified in the presentation informa- 
tion 705 contained in the PTD information 703 further 
5 contained in the ticket application information 302. 
[0076] The ticket data object 403 is transported over 
the transport layer i.e. using the presenting means 260B 
to the receiving means 601 of the inspection system 
106. 

10 [0077] Figure 9B depicts a second possibility for the 
presentation mechanism. The user selects with the help 
of the U/l part 201 of the ticket application 200 a ticket 
300Afrom a modularticket 350 including a bunch of tick- 
ets 300A, 300B, 300C. The ticket application 200 reads 

15 the ticket object 303A, detects from the XML frame in 
the ticket data a keyword 402 indicating a link 404 point- 
ing to the ticket data object 403 of the ticket 300A. Then 
the ticket application 200 reads the ticket data object 
403 which may be stored in the data storage 230. The 

20 ticket data object 403 read is then presented on the pre- 
senting means 260B, such as on the display 261 of the 
mobile device 1 02. The sensor 601 1 of the receiving sys- 
tem 601 , such as a scanner or image recognisation sys- 
tem, of the inspection system 1 06 detects the object 403 

25 on the display 261 .The sensor 601' may also be a trans- 
ducer, digital camera, video camera, and so forth. 
[0078] Figure 10 illustrates closer the operation of the 
ticket application 200 and the ticket storage 230. The 
user requests a modular ticket 350 by sending a request 

30 REQ1 to the front end 1 01 1 A of a ticket issuing system 
1 01 A. The front end 1 01 1 A forwards the request REQ1 
to the back end 1 01 2A of the ticket. There the data con- 
tained in the request REQ1 is checked. Such data may 
include a customer number, billing information, credit 

35 card number, and information identifying the modular 
ticket 350, such as the bus line number, event name, or 
other identifier. 

[0079] The ticket issuing system 1 01 A thus processes 
the request REQ1 and after it has been validated, re- 

40 turns by returning the modular ticket 350 to the mobile 
device 102. The mobile device 102 routes the modular 
ticket 350 to the ticket application 200. This may be im- 
plemented by using SIM Application Toolkit if the mobile 
device is a GSM terminal. The application 200 reads all 

45 short messages coming to the mobile device 102 and 
containing a specific identifier. The ticket application 
stores the modularticket 350 to the ticket storage 230. 
The ticket storage 230 may include ticket type database 
1 0000. The ticket type database contains necessary in- 

50 formation for the ticket application 200 about presenta- 
tion mechanisms, payment, receipts, and it may even 
contain some settings for the U/l part 201 of the ticket 
application 200. The modular ticket 350 is then stored 
into the ticket storage 230. 

55 [0080] The ingredients of the modularticket 350, i.e. 
travel package, airline tickets, are delivered by the issu- 
ers individually. Their format may be specified in each 
ticket issuing system separately. Further, the ticket is- 
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suing system 1 01 may supply some data for the ticket 
application 200, i.e. such as the rules contained in the 
ticket type database 10000. In contrary to the prior art 
solution, this approach requires considerably less sep- 
arate transferring of data. In addition, since there now 
is a logical container for the individual related tickets, 
identifying of the tickets may be automated and it is not 
left up to the user to identify them in the ticket data stor- 
age 230. 

[0081] By using XML schemas it is possible to define 
the contents for the ticket type database 10000. In other 
words, a container of variable data types as defined by 
the user information part 301 of each ticket. The ticket 
type database 1 0000 will serve for storing the individual 
tickets 300 of various types. The tickets 300 consist of 
an XML document comprising user information 301 and 
ticket application information 302, including also ticket 
object 303 with the link 404 to the object 403, and the 
embedded ticket data object 403. 
[0082] By defining the elements and attributes of a ba- 
sic ticket type in an XML schema, the minimum set of 
elements and attributes that any ticket 300 might have 
is spezified. A basic ticket consists of similar XML doc- 
uments with the classical ticket function. It only contains 
user information 301 . 

[0083] Subsequently, by using the XML schema ca- 
pabilities for inheritance from a original data type, third 
party forums and entities can extend the basic ticket 
type through the definition of new XML schemas to suit 
their needs regarding information to the user more ac- 
cording with the type of service provided. These sche- 
mas will need to be stored in the mobile device in the 
ticket storage 230. The schemas, XML documents, can 
be signed by a trusted party and verified by the ticket 
application prior their installation in the database. 
[0084] The XML document forming the ticket 300 in- 
cludes two parts user information 301 , ticket application 
Information 302, and then it has an embedded ticket da- 
ta objet 403. The object 403 which is linked to the ticket 
300 via a I ink 404 defined by a keyword 402 and situated 
in an XML frame 401 in ticket object 303. The ticket data 
object 403 is the only thing to be presented to the in- 
spector by the user in order to get access to the service 
promised. The ticket data object 403 link 404 was iden- 
tified in the XML document by a keyword 402 that would 
indicate the presence of this object to the application 
parser located in the parsing means 202 of the ticket 
application 200. 

[0085] The role of user information 301 is to inform 
the user and in some cases to provide non-repudiation 
services, e.g. through out the signature of the XML doc- 
ument. Also, the verification of the signature does not 
need to be performed by the security means 250. e.g. 
by the secure element 252 of the user's mobile device 
1 02. This will be only necessary in the case of a conflict 
with the entity providing the ticket service. In this case 
the user takes the ticket 300 which is a signed XML doc- 
ument to a referee arbitering the dispute with the service 



provider in order to claim his/her rights. This referee will 
then verify the digital signature of the issuer in the XML 
document and act in consequence. 
[0086] These schemas are used to validate the con- 
5 formity of a given ticket 300 to a stored model, such as 
a model that needs to be compliant to some official reg- 
ulations. The user information 301 is the minimum infor- 
mation necessary for handling electronic tickets in a 
computer server. In the most elementary realisations, 
the tickets are based on text, for example they include 
a ticket unique identifier number TUID. In these cases 
no ticket data object 403 is needed. 
[0087] The definition of new ticket types i.e. the user 
information 301 part of ticket 300 does not preclude of 
utilising the ticket application information 302 to hold a 
link 404 to a proprietary ticket data object 403. Similarly, 
it is possible to select in the ticket issuing system, which 
parts of the ticket 300 may be manipulated. For exam- 
ple, the embedded data object can be a medical pre- 
scription, and the user information part 301 only con- 
tains user information of the user obtaining the prescrip- 
tion. 

[0088] The user may request a prescription by send- 
ing a request REQ2 to the front end of a medical doctor 
site 1 0 1 B. The request REQ2 is processed similarly, and 
in response a ticket 300'" is returned. The ticket 300'" is 
a prescription and contains a similar structure than 
those ticket models discussed above. The processing 
performed for the ticket 300'" in the mobile device 102 
has already been discussed above. As immediately not- 
ed, the issuer of the prescription does not need to call 
a pharmacy any more and the user does not need to call 
the doctor any more because this kind of process can 
be automatised. 

[0089] The cue ticket information elements, such as 
user information 301 , ticket application information 302, 
and ticket object 303 are fully accessible by the user by 
means of the ticket application 200. Examples of such 
means are extensible Structure Language XSL and an 
XML parser. The methods and means to be select de- 
pend, however, on the format of the ticket 300 and the 
ticket data object 403. Similarly, the format of the ticket 
300 and the ticket data object 403 may either enable or 
disable user access to this data. 
[0090] The accessibility to the ticket object requires 
the recognition of the format by the XSL document con- 
tained in the frame 401 . This can be done by the appli- 
cation parser contained in the parsing means 202. The 
user does not need any access to the information inside 
the ticket data object 403 in order to use the ticket 300 , 
for example, for obtaining a service promised by the 
merchant. The ticket application 200 needs to be able 
to extract the ticket data object 403 and present it to the 
inspection system 1 06 or to ticket printer 1 05. 
[0091] The separation of ticket data object 403 and 
cue ticket-info elements, i.e. the user information 301 , 
ticket application information 302, and ticket object 303 
provides many advantages. 
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[0092] By separating the ticket info from the ticket ob- 
ject it is possible to copy protect and sign only the ticket 
object and not the full document thus saving processing 
capacity not only in the mobile device 102, but also in 
the ticket issuing system 1 01 , the ticket printer 1 05, and 
inspection system 106. This is very important in ticket 
applications where a high throughput is desired, such 
as in the ticketing applications used by public transpor- 
tation. Moreover, this approach, with total separation of 
user information and ticket data object, permits the 
back-up (copy) of the user information part, even when 
the ticket data object can not be copied or tranfered. 
[0093] It is only necessary to protect the ticket object 
and not the full document against fraudulent usage. The 
merchant can sign the cue ticket-info elements for pro- 
viding off-line non-repudiation capabilities. 
[0094] The mechanisms employed for this purpose 
will be validated by the merchant during the redemption 
of the ticket object, i.e. in the ticket issuing system 1 01 . 
The merchant can optionally sign the cue ticket-info el- 
ements to provide non-repudiation services of the ticket. 
In the case of a conflict the signed cue ticket-info ele- 
ments can be taken to a referee to resolve the dispute. 
In this case the signed cue ticket-info elements act as a 
digital receipt for the user. 

[0095] As a result of using the invention, the user gets 
consistent user experiences regardless of the type by 
means of cue ticket-info elements in the XML document. 
[0096] By separating the ticket info elements or addi- 
tional objects in the XML document from the real ticket 
it is possible to deliver promotion objects (e.g. ringing 
tones, icons, coupons, etc.) together with the ticket. Fur- 
ther, in the ticket issuing system 101, ticket data object 
403 may be further tailored to suit individual business 
demands. 

[0097] By separating the ticket object 303 from the 
ticket object 403 it is possible to convert the cue ticket- 
info to a more adequate format depending on the mobile 
phones capabilities and preferences of the user without 
lost of integrity of the ticket info or affecting the value of 
the ticket. 

[0098] Further, backward compatibility to legacy dig- 
ital tickets is obtained, and by using the inventional con- 
cept, also bandwidth usage is reduced. This is very im- 
portant in the case of remote redemption, since only the 
ticket data object 403, not the full document, need to be 
presented to the inspection system 106 or ticket printer 
105. 

An electronic ticket can be made to include user infor- 
mation, ticket application information, and ticket data 
further including an object. Further, the ticket data may 
further include a keyword linking the object to the ticket. 
This object may be embedded into a frame, which may 
be for example an XML frame. 

[0099] When issuing electronic tickets user informa- 
tion, ticket application information, and ticket data are 
included into theticket. A link including a predefined key- 
word is included into the ticket data, the link defining a 



ticket data object. Then the electronic ticket is sent to 
the mobile device, or to the personal computer of the 
user having ordered the ticket. 

[0100] The electronic ticket is first received atthemo- 
5 bile device from a ticket issuing system and stored 
thereto. When the ticket is to be presented, the parsing 
means of a ticket application parse the ticket in order to 
detect a predefined keyword in the ticket data. If in the 
parsing the predefined keyword is detected, in response 
10 to the detecting of the keyword a presentation command 
for presenting means is generated in order to present 
the ticket data object defined by the link including the 
keyword. 

[0101] A ticket is used by presenting the ticket data 
15 object identified by a link including a predefined key- 
word. The ticket inspection system or the ticket printer 
checks the presentation of the ticket data object. 
[0102] Different variations of the invention allow the 
handling of access related XML documents of variable 
20 user information content in a modular ticket forming a 
single logical unit. Examples of such modular tickets are 
tickets of given types, such as airline tickets, and the 
receipt of purchase of the tickets. Further examples of 
such modulartickets are tickets for different events, and 
25 a plurality of tickets for one event in which case there is 
a plurality of ticket unique identifiers numbers for the 
bunch of tickets. 

[0103] The tickets may also correspond to medical 
prescriptions with the initial diagnosis, the tickets then 

30 being digitally signed by a medical doctor in the user 
information part of the ticket. The prescriptions may be 
realised also by means of a modular ticket. 
[0104] The benefits of the invention are various. Not 
only code optimisation, but also consistent user experi- 

35 ence is obtained. The user only needs to know how to 
use the ticket application in order to manage a plurality 
of ticket objects. 

[0105] Preferably, the objects have similar content 
types based on XML. 

40 [0106] The security can be provided by the issuer of 
the ticket. For a modular ticket the issuer entity of the 
modular ticket can provide through its digital signature 
to the XML document. The structure of the modulartick- 
et is beneficial in the case that the entity issuing the tick- 

45 et and the entity offering the service are not the same, 
which may happen e.g. in the case that a concert ticket 
is bought at a shopping mall. 

[0107] Last but not least, the presented models also 
provide support for proprietary content for the tickets. In 

50 particular, this is the case when the tickets include XML 
documents that are handled by the ticket application. 
The XML based user information may then be embed- 
ded with a proprietary data object with a description to 
the ticket application about its usage. Such tickets may 

55 be used not only for tickets, but also for receipts, medical 
records, medical prescriptions, hotel vouchers, and for 
other similar purposes. 

[0108] Although the invention was described above 
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with references to the examples shown in the appended 
drawings, it is obvious that the invention is not limited to 
these but it may be modified by those skilled in the art 
without differing from the scope and the spirit of the in- 
vention. The invention has been described by using 5 
XML terminology in the examples, however any other 
suitable language can be used for carrying out the in- 
vention. 

[0109] To summarise, different approaches have 
been suggested to standardise the handling of digital 10 
tickets for mobile platforms as well as the internet. How- 
ever, the generation of complete new standards (i.e. da- 
ta format, syntax, and semantics) on digital tickets are 
likely to exclude existing ticketing schemes based on 
SMS, barcodes, pictures, etc. 15 
[0110] Taking into account that the successful and 
prompt deployment of a digital ticket framework de- 
pends on great measure on accommodating these pro- 
prietary strategies, it is necessary to provide mecha- 
nisms that while providing a consistent user experience 20 
are also capable of accommodating the merchant's leg- 
acy tickets. 

[0111] In addition, in order to make the ticketing 
framework scalable (and therefore, reach most mobile 
phone market segments) it would be highly desirable to 25 
support from the very simple tickets (e.g. based on 
SMS) which are likely to be host in phones with low ca- 
pabilities to more sophisticated tickets (e.g. based 
MMS) for phones with multimedia capabilities. 
[0112] There has been created an XML based Ian- 30 
guage for digital ticket usage. This is the "generalized 
digital ticket definition language", http://www.w3.org/ 
Dsig/signed-XML99/pp/NTT_xml_ticket.html / "Gener- 
al-purpose Digital Ticket Framework"; Ko Fujimura and 
Yoshiaki Nakajima; published in the Proceedings of the 35 
3 rd USENIX Workshop on Electronic Commerce Bos- 
ton, Massachusetts, August 31 - September 3 ; 1998. 
[0113] This language is meant to define individual el- 
ements of the tickets (e.g. Ticketlssuer, TicketID, Ticket 
typelD) that are used by the mobile phone ticket appli- 40 
cation and the merchant's system alike. Thus, in one of 
the advantageous embodiments of the invention, the 
ticket object is actually the full XML document. Conse- 
quently, the XML document will need to be totally up- 
loaded to the merchant for processing and authentica- 45 
tion in order to obtain the service promised by the ticket. 
[0114] In such a proposed solution the ticket will not 
be the XML document itself but it will be wrapped by an 
XML document (see Fig. 11). This means that the XML 
doc will contain a reference to an external entity - the 50 
real ticket object - which will be totally proprietary to the 
merchant (e.g. sms/text, barcode, picture, proprietary 
encoding, etc.). Nonetheless, the XML ticket-informa- 
tion elements will be used to provide a consistent expe- 
rience to the user with regards to the type of ticket, date 55 
of usage, etc. These CUE (Consistent User Experience) 
information elements (cue ticket-info elements) would 
need to be defined by a standardization body such as 



the MeT, while the elements/format required by the tick- 
et inspector's processing systems are left completely 
proprietary to the merchants in order to support back- 
ward compatibility and to suit particular business needs. 
[0115] In other words, the ticket-document will favour- 
ably have two interfaces: (1 ) to the user throughout the 
ticket-info elements (2) to the merchant throughout the 
external ticket entity which contains the real ticket value 
(used by the ticket inspector to validate the ticket and 
grant access to services). 

[01 1 6] While the cue ticket-info elements are fully ac- 
cessible by the user by means of the ticket application 
(through XSL and XML parser), it will depend, however, 
on the format of the ticket object whether user access 
is possible. The accessibility to the ticket object would 
require the ..recognition" of the format by the XSL docu- 
ment and application parser. However, the user does not 
need access to the information inside the ticket object 
in order to obtain the service promised by the merchant. 
The ticket application just needs to be able to extract the 
ticket object and upload it to the ticket inspector. 
[01 1 7] Finally, the separation of ticket object and cue 
ticket-info elements, provides among others the follow- 
ing advantages: 

it is only necessary to protect the ticket object and 
notthefull document against fraudulent usage. The 
mechanism(s) employed for this purpose will be val- 
idated by the merchant during the redemption of the 
ticket object. 

[01 1 8] The merchant can optionally sign the cue tick- 
et-info elements to provide non-repudiation services of 
the ticket. In case of conflict the signed cue ticket-info 
elements can be taken to a referee to resolve the dis- 
pute. In this case the signed cue ticket-info elements act 
as a digital receipt for the user. 

[0119] The following advantages are gained by the 
technical features of the above described embodiment 
of the invention: 

Consistent user experience regardless of the type 
by means of cue ticket-info elements in the XML 
document 

By separating the ticket info elements) or additional 
objects in the XML document from the real ticket it 
is possible to deliver promotion objects (e.g. ringing 
tones, icons, coupons, etc.) together with the ticket. 
By separating the ticket info from the ticket object 
is possible to convert the cue ticket-info to a more 
adequate format (depending on the mobile phones 
capabilities and preferences of the user) without 
lost of integrity of the ticket i nfo or affectin g the value 
of the ticket. 

By separating the ticket info from the ticket object it 
is possible to copy protect/sign only the ticket object 
and not the full document. 

By separating the ticket info from the ticket object, 
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a merchant could sign the cue ticket-info elements 
for providing off-line non-repudiation capabilities. 
Backward compatibility to legacy digital tickets. 
Proprietary description of ticket objects to suit the 
individual business demands. 
Reduce bandwidth usage (important in case of re- 
mote redemption) since it is only the ticket object 
that needs to be uploaded to the tickets inspector 
and not the full document. 



Claims 

1. A device (102) for presenting an electronic ticket 
(300), 

characterised in that 

the device (102) includes 

receiving means (263) for receiving an elec- 
tronic ticket (300) from a ticket issuing system 
(1 01 ), the electronic ticket (300) including user 
information (301), ticket application information 
(302), and ticket object (303), 
a ticket storage (230) for storing at least one 
electronic ticket (300), 

parsing means (202) for detecting a predefined 
keyword (402) in the ticket object (303) thus 
generating a parsing result, 
generation means (206) responsive to the pars- 
ing means (202) for generating a presentation 
command for presenting means (260B) adapt- 
ed to present a ticket data object (403) defined 
by a link including the keyword (402), if the 
parsing result is that the predefined keyword 
(402) is detected. 

2. A device according to claim 1 , 

wherein the presenting means (260) include a dis- 
play (261) for displaying the object (403). 

3. A device according to claim 1 , 

wherein the presenting means (260) include a ra- 
dio frequency tag (265) for beaconing the object 
(403). 

4. A device according to claim 1 , 

wherein the presenting means (260) include a 
loudspeaker (264) for presenting the object (403) 
aurally. 

5. A device according to claim 1 , 

wherein the presenting means (260) include a 
sending means (262) for sending the object (403) 
to a predefined address (ADDR) via a communica- 
tions channel, such as over the air interface. 

6. A device according to claim 1 , 
characterised in that 



the device further includes security means (250) for 
encrypting and/or decrypting, authenticate and/or 
sign (PKI means) the ticket data. 

5 7. A device according to claim 1 or 6, 
characterised in that 

the ticket storage (230) is adapted to store a receipt 
relating the ticket (300). 

10 8. A device according to claim 1 . 6, or 7, 
characterised in that 

it has means for using or storing a modular ticket 
(350) containing a plurality of tickets (300A, 300B, 
300C). 

15 

9. A device according to claim 8. 
characterised in that 

the modular ticket (350) further includes a plurality 
of ticket application identifiers (302A, 302B, 302C) 
20 each relating to specific ticket object (303A, 303B, 
303C) or to one ticket application (200). 

10. A device according to claim 5. 

wherein the predefined address (ADDR) is includ- 
es ed in the ticket application information (302) orticket 
object (303). 

11. A device according to any one of the preceding 
claims, 

30 wherein the parsing means (202) are responsive 
to a request (REQ) received from an inspection sys- 
tem (106). 

12. A device according to claim 5 or 10, 

35 wherein the predefined address (ADDR) is ob- 
tained from a ticket inspection system (105, 1 06). 

13. A device according to any one of the preceding 
claims, 

40 wherein the electronic ticket is an XML document. 

14. A device according to any one of the preceding 
claims, 

wherein said device (102) is a mobile terminal. 

45 

15. A system (1 01 ) for issuing electronic tickets (300), 
characterised in that the system includes 

generating means (501 ) for generating an elec- 
50 tronic ticket (300) including user information 

(301), ticket application information (302), and 
ticket object (303), wherein the generating 
means (501) generate a link including a prede- 
fined keyword (402) into the ticket object (303), 
55 the link defining a ticket data object (403), 

sending means (502) adapted to send the elec- 
tronic ticket (300) and the ticket data object 
(403) to a device (102, 103, 104, 105), espe- 
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cially to a device (1 02) according to any one of 
the claims 1 to 14. 

16. A system according to claim 15, 

wherein the ticket data object (403) is embedded 
to the electronic ticket (300) or into the ticket object 
(303). 

17. A system according to claim 15 or 16, 
characterised in that 

the generating means (501) further store a prede- 
fined address (ADDR) to the ticket application infor- 
mation (302) or to ticket object (303) of the electron- 
ic ticket (300). 

1 8. A system according to claim 15, 1 6, or 1 7, 
characterised in that 

the generating means (501) are further adapted to 
store a predefined address (ADDR) to the ticket ap- 
plication information (302) or to ticket object (303). 

19. A system according to claim 15, 16, 17, or 18, 
characterised in that 

the generating means (501 ) further store a plurality 



21. A system according to claim 15, 1 6, 17, 18 or 1 9, 
wherein the object (403) is embedded into the XML 
frame 401 . 

22. A system including 

a system (101) for issuing electronic tickets, 
adapted to send electronic tickets (300) to a de- 
vice (102), an electronic ticket (300) including 
user information (301), ticket application infor- 
mation (302), and ticket object (303), the sys- 
tem (101) particularly according to any one of 
the claims 1 5-21 , 

a device (1 02) for presenting an electronic tick- 
et comprising i) aticket storage (230) for storing 
at least one electronic ticket (300), ii) parsing 
means (202) for detecting a predefined key- 
word (402) in the ticket object (303), and iii) 
generation means (206) responsive to the pars- 
ing means (202) for generating a presentation 
command for presenting means (260B) if the 
parsing result is that the predefined keyword 
(402) is detected, the device (102) particularly 
according to any one of the claims 1 -1 4, and 
a device (105, 106) for inspecting electronic 



tickets (300), the device (105, 106) having pre- 
defined address (ADDR) and including i) re- 
ceiving means (601) for receiving a ticket data 
object (403) from a device (1 02), the ticket data 

5 object (403) being defined in the device (1 02) 

by a link including a keyword (402), ii) checking 
means (603) for checking the contents of the 
object (403) received, the means producing a 
checking result, and iii) entry means (605) re- 

10 sponsive to the checking means, adapted to al- 

low entry, if the checking result shows that the 
ticket data object (403) corresponds to a valid 
ticket (300), and/or forbid entry in the opposite 
case. 

15 

23. A system according to claim 22, 
characterised in that 

the ticket (300) includes an XML frame (401 ) and a 
ticket data object (403). 

20 

24. An electronic ticket (300), 
characterised in that 

the ticket includes 

user information (301), 
ticket application information (302), and 
a ticket object (303) further including a ticket 
data object (403), the electronic ticket (300) 
particularly for use in a device and/or system 
according to any one of the claims 1 to 23. 

25. An electronic ticket (300) according to claim 24, 
wherein the ticket object (303) further includes a 
keyword linking the ticket data object (403) to the 

35 electronic ticket (300). 

26. An electronic ticket (300) according to claim 24 or 

25, 

wherein the ticket data object (403) is embedded 
40 into a frame (401). 

27. An electronic ticket (300) according to claim 26, 
wherein said frame (401) is an XML frame. 

45 28. An electronic ticket (300) according to any one of 
claims 24-27, 
characterised in that 

the ticket (300) further includes a promotional object 
or an external reference thereto. 

50 

29. Aticket according to claim 28, 
characterised in that 

said promotional object is a ringing tone or an icon. 

55 30. A modular electronic ticket (350) 
characterised in that 

the modular electronic ticket (350) includes an XLM 
document divided into several XML parts, the parts 



of ticket object (303A, 303B, 303C) for one user in- 25 
formation (301) and/or some ticket application in- 
formation (302, 302A, 302B, 302C), thus forming a 
modular electronic ticket (350). 

20. A system according to claim 15, 16, 17, 18 or 1 9, 30 
wherein the ticket object (303) includes an XML 
frame (401). 



45 



50 
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further including 

user information (301), and 
individual tickets (300A, 300B, 300C) accord- 
ing to any one of the claims 24-29, the individ- 5 
ual tickets (300A, 300B, 300C) including 
user information (301 A, 301 B, 301 C), and 
ticket application information (302A, 302B, 
302C), the ticket application information (302A, 
302B, 302C) including a part for a ticket object 10 
(303A, 303B, 303C) with a link (404A, 404B, 
404C) including a keyword (402A, 402B, 402C) 
to a ticket data object (403A, 403B, 403C), the 
ticket data object (403A, 403B, 403C) being 
presented by a device (102) when the ticket 15 
(300A, 300B, 300C) is to be used. 

31 . Means for performing an operation on an electronic 
ticket (300A, 300B, 300C) according to any one of 
the claims 24-30, the electronic ticket including at 20 
least one XML based documents whose model in- 
cludes user information that derives through XLM 
schemas from a basic user information (301) type, 
several of these tickets (300A, 300B, 300C) being 
delivered together using the stucture provided by 25 
the modular ticket (350). 
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